-------------------------------------------------------------------------------
PROBLEM ATTIC
-------------------------------------------------------------------------------

We've had a lot of letters in the Problem Attic postbag this month asking about
hardware scrolling, and how it can be used in Basic programs. Well, this is
rather too complicated a subject for a straightforward three-paragraph reply -
three pages would be more like it. Normally at such times we just mutter 'Not
enough space' and move on to the letters we can answer briefly.
    It's a pretty interesting subject though, and it neatly ties in with a
letter in last month's PA about Ghosts and Goblins. Just this once then, we're
going to give a complicated subject the space it needs - but you needn't think
we're going to make a habit of it.

Vertical scrolling is very easy, and there's no real problem adding it to Basic
games. This program illustrates scrolling the screen up and down.

[Listing - VSCROLL.BAS]

[A correction to this listing was published in the December 1986 issue (#15),
which fixed an error in line 10; "POS(0#)" should have read "POS(#0)".]

This doesn't do anything very impressive, but you should be able to get the
general idea from the comments on each line.
    Horizontal scrolling isn't anywhere near so easy. If you want to scroll the
screen sideways from Basic you'll need to use the OUT command, which sends a
number to a peripheral chip. That'll be enough to put quite a lot of people
off, but it isn't too difficult. The only problem is that it messes up the way
Arnold writes things to the screen. This listing should give you an idea what I
mean:

[Listing - HSCROLL.BAS]

As you'll see if you run this, Arnold can't cope with the changes you've made.
All printing carries on as if the screen was still unscrolled. To get your
screen back to normal you can either type MODE 2, or force a vertical scroll
using the cursor keys.
    This last point is another reason why the OUT method of horizontal
scrolling doesn't work too well. Every time you force a vertical scroll using
the simple method we started with, you undo any horizontal scrolling you've
done using OUT.
    Horizontal scrolling is much easier if you know a little machine-code. Two
firmware routines make the programming very easy indeed, and they let Arnold
know what you're doing so he can print to the screen properly.

NON-TECHNICAL

To start with, here's a Basic program which uses the firmware routines. You
don't need to know a thing about machine-code to use them, but there's an
explanation afterwards for anyone who's interested.

[Listing - HSCROLL2.BAS]

The important bits of the program are lines 10 to 70 which set up the scroll
routines, and line 180 which dismantles them after you've finished with them.
If you start your program with the commands in lines 10-70 and finish with the
MEMORY command from line 180, you can use the commands CALL scleft and CALL
scright whenever you want to scroll the screen left or right.

BOFFINS ONLY

That's all you need to know to use the routines from Basic. If you're
interested though, here's how the first routine disassembles:

scleft:   CALL &BC0C     ;SCR-GET-LOCATION
          ;No entry conditions -- on exit, HL
          ;contains the current 'screen offset'.
          INC  HL        ;Increases HL
          INC  HL        ;by two.
          JP   &BC05     ;SCR-SET-OFFSET
          ;Value in HL is used as new 'screen
          ;offset'.

The second one's the same, but with DECs instead of INCs. In other words, one
increases the 'screen offset' by two and the other decreases it by two.
    Clearly the screen offset is the key to horizontal scrolling - increase it
by two to scroll left a fortieth of a screen's width, or decrease it by two to
scroll right. It's also, incidentally, the key to vertical hardware scrolling
from machine-code. Increase the offset by 80 (decimal) to scoll up one line, or
decrease it similarly to scroll down. This accounts for something you'll have
noticed with the Basic horizontal-scroll program: scrolling left or right by a
whole screenful also scrolls the screen up or down one line.
    None of this tells you what the screen offset actually is, but we'd be here
all day if I tried explaining that. If you're really keen to know about such
things get hold of Amsoft's CPC Firmware Guide, read it and inwardly digest it.
Once you've done that, you'll be ready for the technical stuff that follows.

GHOSTS AND GOBLINS

Yes, it's that horrifying saga of colour modulators producing black-and-white
pictures again. This isn't a change of subject though, since it turns out that
a clever scrolling technique is the culprit.
    For those who missed last month's Problem Attic, the tale goes like this.
Software house Elite produced the AA Rave game Ghosts and Goblins a couple of
months back, believing it to be compatible across the CPC range. Imagine their
(and our) surprise when it turned out to be incompatible with Amstrad's TV
modulator, producing only a black-and-white picture even on a colour TV set.
    Compatibility problems between machines happen all the time, but this was
the first time we'd heard of modulator problems. The modulator simply converts
the RGB (red-green-blue) signal meant for a colour monitor into the modulated
signal which most TV sets require through their antenna socket. For Ghosts and
Goblins to mess up the modulator output, it had to be doing some very strange
things with the RGB signal.
    Needless to say, it was. To be precise it was moving the 'logical' screen
(ie. the picture of the ghosts, goblins etc) backwards and forwards across the
surface of the 'physical' screen (ie. the hard glass bit you look at). You can
see this effect for yourself, with this little bit of Basic. It replaces lines
80-180 of the poked-in machine-code horizontal scroll listing, so these must be
deleted before typing in the new lines.

80 FOR a=1 TO 50
90 CALL &BD19
100 OUT &BC00,3:OUT &BD00,5
110 CALL &BD19
120 OUT &BC00,3:OUT &BD00,&8E
130 NEXT a
140 MEMORY oldmem

[The modified listing is saved as HSCROLL3.BAS.]

This looks ugly, and would probably give you a headache if you stared at it for
too long. If you're looking at it through a modulator, it should also look
distinctly colourless. (I don't have a modulator to test this, but I'm pretty
sure of it.) Now you know what Ghosts and Goblins does, so the next question
is 'Why?'

Pixel detail from Ghosts'n'Goblins
[Screenshot of Ghosts'n Goblins]

PROBLEMS WITH SCROLLING

A couple of issues ago I made some bold statements about Arnold's hardware
scrolling capabilities compared to those of other machines. In fact, Arnold's
hardware scroll does have one slight problem: it's too fast.
    As you may remember, the horizontal scroll routines can only scroll the
screen a fortieth of its width at a time. That's not just the way the routines
are written: the hardware simply can't manage a smaller scrolling action.

Fast scrolling on Vortex's TLL
[Screenshot of TLL]

    To get a smooth continuous scroll you need to make one scrolling movement
every fiftieth of a second - the timing for this is handled in our scrolling
programs by those CALL &BD19 statements. If there are fifty movements per
second, and they each have to be at least a fortieth of the screen width,
you're clearly going to scroll past a whole new screen of landscape in less
than a second.
    This is too fast for anything much more than reflex gameplay, though
Vortex's TLL did quite well using these techniques. Another notable hardware
scroller was Gremlin's Thing on a Spring, though there were slight problems at
the screen edges on this one.
    For the most part games programmers use either software scrolling or what
you might call 'burst' scrolling. Software scroll only works well on very small
windows (eg Rambo, Stainless Steel) and causes an ugly rippling effect if used
on large areas - Bounder and the tank stage of Beach-Head are cases in point.
    The preferred technique is 'burst' scrolling - keeping the screen fixed
until the player reaches the edge of it, and then fast-scrolling the next
screen into position. Prime examples of this are Green Beret and Thrust. This
is still far from perfect, and it was an attempt to improve on this that
brought Ghosts and Goblins its problems.

THE 'SOLUTION'

The aim in Ghosts and Goblins was to provide a slow hardware scroll, so that
the 'burst' scrolling wouldn't be so abrupt as it is in, for example, Green
Beret. The method used involved both scrolling the screen and moving it.
    If you've typed in the program so far, you can get a Ghosts and
Goblins-style scroll by altering line 100 as shown below. If you haven't, here
it is in full:

[Listing - HSCROLL4.BAS]

The OUT commands in lines 100 and 120 move the screen left and right by an
eightieth of its width - you'll have seen this already if you've been typing
things in and running them as you've been reading. (Note that 'moving' is not
the same as 'scrolling' - I'll explain the difference in a minute.) The
difference now is that 'CALL scleft' in line 100.

Green Beret uses Burst scrolling
[Screenshot of Green Beret]

    The CALL in line 100 scrolls the screen left by a fortieth of its width,
and the OUTs move it back to the right by an eightieth: net result, a
scroll/move of an eightieth to the left. A fiftieth of a second later the OUTs
in line 120 move the screen to the left by an eightieth. After another fifieth
of a second line 100 scrolls/moves the screen another eightieth to the left,
and so on.
    If you've still got the default colours on screen you won't be able to see
this happening: it just looks like a slow smooth scroll. Set the border and
screen background to different colours and you'll be able to see what's
happening quite clearly - the left and right edges of the screen blur where
it's being moved rapidly from side to side. Here 'moving' literally means
changing where the detailed picture part of Arnold's display appears on the
glass tube of the monitor.

NOW YOU TRY IT

This method is a very nice way of halving the scroll speed without losing
smoothness, and could usefully be applied to Basic versions of Scramble and
similar scrolling games. You'd need to do the timing with the EVERY command
rather than using CALL &BD19 or FRAME, and make sure the scroll/move commands
were on a higher timer priority than any other interrupt-driven sequence you
had running.
    Another good idea is to blank off the blurred columns at each side
alternately - the right-hand one at line 100 and the left-hand one at line 120.
If you set these to the same colour as the border you cut the apparent screen
width down a little, but the loss of that unsightly 'edge-flicker' more than
makes up for this.
    If you can make a decent scrolling game out of any of this, why not send it
in to Type-Ins? Make sure you keep it short - under 3K if possible - and give
it plenty of grab-factor. Otherwise it's up to you: knock our socks off and
we'll print your program!

BUT BEAR IN MIND ...

There are problems with this kind of technique. For one thing, OUTs like the
ones in lines 100-120 bypass Arnold's firmware. In this case they work on all
the machines I can find to try them on, but you can't run crying to Alan Sugar
if you get compatibility problems - Amsoft advises software houses not to use
them.
    More seriously, it looks like Amstrad's modulators can't produce a colour
TV signal out of this kind of monitor input. One (non-Elite) programmer I met
at the PCW show put it down to the poor quality of the Amstrad units. If this
is true it's not exactly surprising: after all, Amstrad keeps costs down by
cutting specifications fine. The modulator works okay for normal purposes, and
Amstrad can hardly be blamed if it can't cope with Ghosts and Goblins.
    That's certainly not to say that Elite is to blame: indeed I'd say the
company has been been unlucky. I don't think anyone in the industry expected
this kind of problem, and other houses are just grateful it didn't happen to
them.
    Moral: Those who live on the cutting edge of technology will be sacrificed
upon it, as Adam Osborne said. Or they get a bit of bad publicity, at any rate.


        /\
      /    \
    /        \
  T Y P E  I N S
/________________\


POSTER MAKER

Ingenious program, this, from PETER DOEL. It produces a giant printout of
whatever you've got on the screen, using eight sheets of normal continuous
stationery. The printer uses the computer's normal character set, so that when
you look at the printout close up you can barely make out what it is. But stick
the pages together, walk away 20 feet, then turn round and look and...WOW!
    You can change the 'contrast' in your giant picture by altering the
characters separated by commas in line 240 - each of these characters
corresponds to one of the 16 possible screen colours.
    The program starts at line 100, and if you just run it as it is, it will
simply produce a magnified printout of the text that's on the screen. A better
idea is to add some more program lines below line 100 to create something
interesting on screen, even if it's just loading in a loading screen from a
game.

10 MODE 0:FOR i=2 TO 13: PEN i:PRINT"   AMSTRAD ACTION":PRINT"":NEXT

Adding this line creates one very simple screen display for turning into a
poster. You could replace it with any other graphics routine, for example one
which loads in a screen display from a graphics package or (if you're clever)
the title screen of a game.

[Listing - POSTER.BAS]


TORUS

Here's another of those listings that take three minutes to type in, yet give a
very, very pretty demonstration of the Amstrad's graphic capabilities. In fact
the program takes longer to run than it does to type in! Nice one, ROGER WILSON
of Blackburn.

[Listing - TORUS.BAS]


SIMON

You probably remember the game in which you have to remember a sequence of
coloured lights and sounds and repeat it. This is that game. Simple, but
challenging and surprisingly addictive.
    This program mimics the game very nicely indeed, giving you a choice of two
playing speeds.
    So, with your Amstrad you can copy a game that took the Christmas market by
storm ten years ago at a cost of 20!
    Our thanks to T MAGEE of Marlow, Bucks.

[Listing - SIMON.BAS]

[Amstrad Action forgot to mention that Simon only works on CPC664 and CPC6128
machines. An apology was published in the December 1986 issue (#15). There is
also a minor bug: when entering the playing speed, you must enter F or S in
upper case. The program does not accept lower case letters. Amstrad Action did
not print a correction in any subsequent issues.]


[The letter below was published in the "Re-Action" column in the Christmas 1986
issue (#16). Amstrad Action offer another apology regarding Simon, in addition
to the one that was published in the December 1986 issue (#15).]

Simple Simon
Oh, dear me, you've made a boob. In the November type-ins the Simon program had
four errors in it. Or was this written on a machine other than a 464?
Daryl Wardle
Wentbridge, Yorkshire

Yes, Daryl, we flubbed it. We omitted to say that Simon was for the 664 or 6128
only.


[The letter below was published in the "Problem Attic" column in the July 1987
issue (#22). Amstrad Action suggest some alterations to Simon to make it work
on CPC464 machines. However, the game still does not work properly because some
CLEAR INPUT commands are still present. Also, the modifications remove the
colour from the game, which makes it much more difficult to play, as the player
must rely on sound alone, instead of sound and colour.]

Simon says...
AA 14 had a listing called Simon Says. Having typed it in and run it numerous
times, I keep getting a syntax error in line 280. Why is this? The line reads:
+-----------------------------------------------------------------------------+
| 280 BORDER 0:INK 0,0:INK 1,26:INK 2,6:INK 3,24:INK 4,18:INK 5,2:MOVE 0,0,1: |
|     RETURN                                                                  |
+-----------------------------------------------------------------------------+
I've given up in despair and wonder if there is a typing error. My machine is a
464.
Mrs J Wandless
Newcastle-upon-Tyne

There is nothing wrong with your typing or the listing. The problem lies with
the computer. Don't panic: your machine is not faulty. The listing is for the
664 or 6128. At the time we did not realise this and did not mention it in the
text. If you want to use the program on the 464, alter the lines below. Note,
however, that you won't get the same display - which may make the game awkward
to play.
+-----------------------------------------------------------------------------+
| 280 BORDER 0:INK 0,0:INK 1,26:INK 2,6:INK 3,24:INK 4,18:INK 5,2:MOVE 0,0:   |
|     RETURN                                                                  |
| 290 FOR d=1 TO 4:MOVE d*100,250:DRAWR 75,0:DRAWR 0,-75:DRAWR -75,0:DRAWR    |
|     0,75:MOVER -10,10                                                       |
+-----------------------------------------------------------------------------+
